This Page Is Inserted by IFW Operations 
and is not a part of the Official Record 



BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of the 
original documents submitted by the applicant 

Defects in the images may include (but are not limited to): 

• BLACK BORDERS 

• TEXT CUT OFF AT TOP, BOTTOM OR SIDES 

• FADED TEXT 

• ILLEGIBLE TEXT 

• SKEWED/SLANTED IMAGES 

• COLORED PHOTOS 

• BLACK OR VERY BLACK AND WHITE DARK PHOTOS 

• GRAY SCALE DOCUMENTS 

IMAGES ARE BEST AVAILABLE COPY. 



As rescanning documents will not correct images, 
please do not report the images to the 
Image Problems Mailbox. 



{fit* 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



Publication number: 



0 286 361 

A2 



© Application number: 88303029.8 
(§) Date of filing: 05.04.88 



EUROPEAN PATENT APPLICATION 

© mt. ci." G06F 11/00 



\3y Priority: 08.04.87 US 35802 




Applicant: WESTINGHOUSE ELECTRIC 


© Date of publication of application: 




CORPORATION 




Westlnghouse Building Gateway Center 


12.10.88 Bulletin 88/41 




Pittsburgh Pennsylvania 15222(US) 


© Designated Contracting States: 




Inventor: DeLucla. R. Ralph 


BE CH DE ES FR GB IT LI SE 




467 Fulton Drive 






Valencia, PA 16059(US) 






Inventor: CasteeL Eric Phillip 






5100 Beatty Drive 






Irwin, PA 15642(US) 






Inventor: Wolf, Daniel Joseph 






1515 Lucille Drive 






Pittsburgh, PA 15234(US) 




© 


Representative: van Berlyn, Ronald Gilbert 






23, Centre Heights 






London, NW3 6JG(GB) 



© Verification of computer software. 



A computer program source code having a known format is divided into units and verified, unit by unit, by 
automatically instrumenting the code and generating a test driver program which executes all branches of an 
instrumented code unit. Processors are used to generate a test driver program and to standardize the code 
format and to insert executable tracer statements into each block of reformatted code between control 
statements. A pseudocode having only control statements and tables identifying valid linkages between blocks of 
code are generated by another processor for use by a verifier in selecting values of input variables and expected 
outputs for test cases which execute each biock of code in the selected unit. Results of the test cases are 
printed out indicating the sequence of block linkages generated by each test case, the expected output values 
and the actual output values. 
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VERIFICATION OF COMPUTER SOFTWARE 



BACKGROUND OF THE INVENTION 
Field of the Invention : 

5 

This invention relates to a method and apparatus for testing new and revised computer programs by 
automatically generating, executing and documenting a customized test program, requiring minimal input or 
intervention by the user. 

70 

Background Information : 

Many plant processes now-a-days are monitored, and to a varying degree controlled in the plant control 
room using signals sent from sending units and instrumentation located throughout the plant. A typical 

15 example of such a process plant is a nuclear power plant. Although many operations in the control room are 
manual, the remaining majority are automatically performed through circuitry involving programmed micro- 
processors or programmable digital computers. Many of the programs used in these microprocessors and 
computers are critical to safe plant operation and consequently, their accuracy and integrity is important 
In a typical power plant there can be about 1200 or more of these control and monitoring programs. 

20 Currently they are verified and validated through a "visual examination of the code coupled with an 
independent physical testing of each program segment to ensure proper operation of the program. Although 
the visual review has proved to be very effective in validating a program. Regulatory Guideline 1.97 issued 
by the Nuclear Regulatory Commission of the United States requires that equipment which provides data 
acquisitions and qualified display functions within the control room be tested in a more stringent manner. 

25 The physical tests have been performed till now using a demonstration unit of the actual hardware which 
permits access to the memory locations for the input parameters and output parameters. In order to isolate 
the piece of software to be tested, the desired test values of the input parameters are entered directly into 
the assigned memory locations in the demonstration unit, and the program is run. The outputs are extracted 
from the output memory locations for manual comparison with the expected values. 

30 Such testing imposes the full burden on the verifier to devise a test program which executes all 
instructions and all possible branches in the program. This requires a great deal of skill on the part of the 
verifier and there is no direct record that all paths of the program have been exercised. Furthermore, since 
each program may require a multitude of tests to exercise all branches, the process becomes extremely 
time consuming and complex. 

35 Accordingly, it is a primary object of the present invention to provide a method and apparatus for 
testing computer programs which automatically generate, execute and document a customized test program 
using minimal user input. 

40 SUMMARY OF THE INVENTION 

The invention in its broad form resides in apparatus and method of verifying a computer program 
source code having known format and a series of program statements including non-control and control 
statements by which the program can branch to alternative program statements of the source code, said 

45 method comprising: operating a processor to standardize the format of the source code to a set of 
prescribed formatting standards to generaio a reformatted source code; characterized by the steps of: 
selecting a target unit of the reformatted source code for verification; instrumenting said target unit of the 
reformatted code by operating a processor to divide said target unit into blocks of code, a block of code 
being marked by the non-control statements between control statements, and to insert into said blocks of 

so code executable instructions to write an identifier into an output file for each block of code when it is 
executed; selecting test cases for said target unit of code with each test case comprising input values for 
variables in the target unit and expected output values, said test cases being selected such that each block 
of code in the test unit is executed; operating a processor to generate a test driver routine to implement 
said test cases; operating a processor to compile and link the test driver routine with the instrumented 
target unit of code; executing the compiled/linked test driver routine and instrumented target unit of code; 
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and generating an output presenting actual output values and expected output values for 9ach test case, 
and a sequential iisting from saia output file of the block identifiers of the blocks of said target unit coae »n 
the seauence ;n which they were executed. 

Described herein is a method of instrumenting a source code to be verified in a process program and 

s of generating a test driver program which is compiled and linked to the instrumented source code to 
successively execute the source code to implement a series of test cases. The source code is instrumented 
by processors to generate, when the code is executed, an indication for each block of code that the 
statements of- that block have been executed. A block of code comprises the program statements between 
control statements. Thus, when the instrumented code is executed by the test driver program, an output is 

?o generated indicating the blocks of code which have been executed. Through a properly devised series of 
tests, all of the blocks of code are executed. The test cases are generated by selecting values for the input 
variables of the target code. The expected values for the output variables of the target code are also 
determined, so that the actual program output values generated by execution of the test cases can be 
verified. 

*s Preferably, the source code to be verified is first reformatted in accordance with a standardized set of 
formatting rules to produce a standardized reformatted source code. This reformatted source code is then 
instrumented and verified one unit at a time, a unit being a routine or other convenient portion of the source 
code. 

In instrumenting the source code, non-executable comments with a unique block identifier are inserted 
20 at the beginning and end of each block of the target unit of code. A block data table is generated listing the 
block identifiers, the nesting level of each block, the block identifier through which each block is entered, 
and an indication of whether a block is a loop back block. A block linkage table is also generated from the 
control statements setting forth all valid transitions between blocks. An executable instruction is then 
inserted at the beginning of the block to inform an output file regarding the block identifier when the block is 
25 executed. Another executable instruction is inserted at the end of the block indicating the block to which 
control reverts after all the statements in the block have been executed. As the program is executed by the 
test driver, the block identifiers are written to a one dimensional array in an output file when each block is 
executed. 

Where the target code unit calls another routine, executable write instructions are inserted by a 
30 processor before and after the call statement to generate in the output documentation an indication that the 

call statement was reached and that the program returned to the correct location after the call. If desired. 

instructions for writing to the output file the value of selected variables before and after the call can also be 

inserted by the processor into the target code unit. 

Also, as described herein and preferably, a pseudocode can be generated by a pseudocode processor 
35 from the reformatted target code unit. The pseudocode contains only the control statements, with comments 

between -identifying the blocks of code using the same identifiers as the instrumented code.;, The 

pseudocode processor can also generate the block data table and linkage table generated by the 

instrumenting processor. 

The verifier examines the source code, all available documentation and the pseudocode and block data 
40 and linkage tables generated by the pseudocode processor to select test cases which wilt execute all 
blocks of the target code unit. The selected values of input variables and expected outputs for each test 
case are entered through a user-friendly interface and arranged by a test generator processor in a variable 
file. The Test Data Processor then uses this data to generate a test driver program for implementing the 
test cases. The variable file can also be used to determine which test cases are affected when a variable is 
45 changed. The test driver processor also generates a test specification which sets forth the inputs, expected 
outputs and block linkages for each test case implemented by the test driver program. 

The test driver program is compiled and linked with the instrumented target code unit and the resultant 
program is executed to successively execute the target code unit for each test case. Final documentation 
includes: in addition to the pseudocode, the block data and linkage tables, and the software test 
so specification, outputs listing the values of the input variables, the actual values of the output variables 
together with the expected values, and the actual sequence of block linkages. 

The invention, which encompasses both the method and apparatus for verifying computer source code, 
simplifies the verification process so that it can be carried out more rapidly and with a greater degree of 
standardization and confidence than is presently available. 

55 
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BRIEF DESCRIPTION OF THE DRAWINGS 

A full understanding of the invention can be gained from the following descnction of the oreferrec 
embodiments given by way of example only and to be reac in conjunction with the accompanying drawings 
in which: 

Figures la, 1b. and 1c when joined together side by side as indicated by the circled tags, illustrate a 
flowchart of the automated software verification system of an embodiment of the invention: 

Figure 2 illustrates the organization of a module of exemplary software to be venfiec by tne nventicn: 
Figures 3 through 6 illustrate examples of formatting ruies used in the exemplary embociment of the 
invention to standardize formatting of the target code; 

Figures 7a and 7b illustrate a piece of target code reformatted in accordance with the standardize 
formatting ruies of the exemplary embodiment of the invention: 

Figure 8 illustrates a piece of pseudocode generated as applicable in the invention: 
Figures 9a, 9b and 9c taken together illustrate a segment of target code fully instrumented in 
accordance with the exemplary embodiment of the invention: 

Figures 10a, lOb, and 10c taken together illustrate a user specified information file list generated by 
the test generator processor in accordance with said exemplary embodiment of the invention; 

Figure 11 illustrates portions of a test driver program generated by the test data processor in 
accordance with the exemplary embodiment of the invention; 

* Figures 12 and 13 illustrate portions of the software test program file generated by the test data 
processor in accordance with the exemplary embodiment of the invention: 

Figure 14 illustrates the formatting of output results in accordance with the exemplary embodiment of 
the invention; and 

Figure 15 illustrates schematically, in block diagram form, a system for carrying out the invention. . 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

The invention will be described as applied to automatically verifying applications software for the 
30 microprocessors in a digital, integrated protection and control system for a nuclear power plant. However, it 
will become apparent that the invention is equally applicable to verifying all types of software. 



General Description : 

35 

The automated software verification system of the invention includes a series of computer programs, 
some interactive, used for testing target computer programs by automatically generating, executing and 
documenting a customized test program using minimal user input. Verification is carried out on a general 
purpose digital computer, even though the target programs may be designed for use on microprocessors. 
40 The software system is divided into a number of independent processors to facilitate modifications to the 
system. 

The initial step in the verification process is standardization of the formatting of the target program 
source code. The formatting used by various programmers, and indeed the formatting of an individual 
programmer within a given program, can vary considerably. The initial processor reformats the entire 

45 source code according to standardized rules. While this formatting is not essential to the practice of the 
invention, it simplifies the tasks of the other processors. A specific program from the target program system 
is then extracted for testing from the reformatted file. A pseudocode generator then extracts from the target 
program an informational listing of only the control statements in the target program. These control 
statements are identified as blocks and given a block number. The pseudocode generator also generates a 

so block data table indicating how each of the blocks is entered and identifying whether the block is a loop 
back or not. In addition a linkage table is generated which identifies all valid branching between pairs of 
blocks. This informational block data table and linkage table are made available to the human verifier for 
use in setting up the test program. 

In a parallel path, a commented code processor inserts block identification comments corresponding to 

55 those used by the pseudocode generator into the target source code. A code instrumentation processor 
then inserts executable tracer statements into each block of the source code. These tracer statements are 
printed out when the test is run to verify that each of the blocks has in fact been exercised. This 
instrumented code is then ready for testing. The human verifier examines the target source code along with 

4 
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•he program software design specification, and any other documentation available, and together with the 
nformaticnal block data table and Mnkage table selects test conditions which will exercise. ail branches of 
the program. In oomg this, the verifier selects input values for the various variables and determines what the 
expected output values snouid be. For a complex program this may involve the generation of many test 
5 cases. 



Detail Description : 

io A flow chart of the automated software verification system of the invention is set forth in Figures 1a. b. 
and c. The verifier, the person to test the target code, receives a file of programs to be tested i along with 
a design specification 2 written by the programmer. The verifier must analyze the target code and its 
documentation to ensure that the documentation is adequate and accurate, and must exercise the actual 
target code through a custom-built test driver program which verifies that the target code operates properly. 

is It will be noted from Figures 1a, b, and c that there are two separate parallel branches A and B m the 
functional diagram. Branch A depicts a series of processors which condition the target code by inserting 
state ments so that upon execution there will be means to trace and record the path of execution as well as 
all input and output values for each test case within the verification process. This is the primary function of 
items 3-7 in Figures 1a and b. These trace statements and input output values provide the necessary 

20 documentation for the verification process when the target code is executed. 

Branch B depicts the review and test specification process. Using the design specification 2 written by 
the programmer describing the purpose of the target code, and viewing a copy of the original code 1. the 
verifier must select 9 a series of test cases with an appropriate input value to test all "of the existing 
branches within the instrumented code, while also confirming that the output values are predictable and 

25 accurate. This procedure is identical and just as strenuous with as without the automatic software 
verification system, but the data input, code conditioning and generation of control statements is greatly 
simplified by this system. The verifier enters 10 the input and expected output values for each test case, 
and branch B processes the test data entered 11, and generates 12 a test driver programmer that will 
execute the "conditioned" code generated in branch A. 

ic All of the processors implemented within the exemplary automated software verification system -were 
developed with PLM86, used by Intel 'Corporation in their microprocessors, as the target language. It is 
important to understand that the basic guidelines around which these processors were developed are 
universal to any block-structured language and thus these processors can be modified so that they can 
handle a wide variety of programming languages such as for instance, Pascal. PL1. and Structured 

35 FORTRAN, among others. A program source file for Intel PLM86 is referred to as a "MODULE". In order to 
provide an orderly mechanism so each piece of software within the total software hierarchy can be quickly 
and easily tagged, the following conventions have been implemented: Each 'MODULE* within the total 
software system is uniquely identified with a five (5) character alpha-numeric base designator followed by a 
three (3) character alpha-numeric extension. 

EXAMPLE: TA028.PLM. RA039.ASM. FI007.1NC, FD020.DEC. 



45 The first two letters (i.e. TA, RA. Fl, FD) are utilized to categorize the software 'MODULE' by software 
systenrvsub-system. 

The next three numbers (i.e. 028. 039. 007, 020) identify a unique 'MODULE' within a specific software 
systenrvsub-system. 

The last three letters (i.e. the extension portion) denote a specification functional type of PLM86 source 

so file: 

PLM - PL M86 program source file 
ASM - PLM86 assembly program source file 
INC - PLM86 Include file 
DEC - PLM86 Declaration file 
55 A PLM86 program source file (i.e. "MODULE" in PLM86 terminology) may contain anywhere from 1 to 99 
subprograms, which are commonly referred to as procedures or functions, or in PLM86 terminology. 
"UNITS". The actual PLM86 program source file itself consists of three functional parts: 



5 
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... 3 1. Header portion 

The 'MODULE" "header" contains aff the source code (including comment :ines) within a 'MODULE' 
exclusive of: (1) The. module's "end" statement, and (2) all the code reauired :o implement a pubiicly or 
5 locally declared subprogram (i.e. procedure or function) within the 'MODULE*. 

EXAMPLE: TA028.HDR is the header portion only of software 'MODULE' TA028. 

1Q 

2. Program portion 

The individual subprograms that exist within the 'MODULE*. These subprograms are numbered 
sequentially from one (1) to ninety-nine (99) according to their physical order within the 'MODULE'. Each of 
;s these subprograms within the 'MODULE' are called 'UNITS'. 

EXAMPLE: TA02823.UNT is the twenty-third "UNIT" within "MODULE" TA028. 

20 

3. End portion 

That part of the 'MODULE* which follows the end of the last subprogram. 

25 

EXAMPLE: TA028.END is the end portion only of software "MODULE" TA028. 



The physical structure of a PLM86 'MODULE' is illustrated in Figure 2. As shown there, the module 20 
30 includes a header portion 21, a series of up to 99 subprograms or 'UNITS' 22, and an end portion 23. 

As shown in block 3 of Figure la. the code preprocessor (CPP) reformats the file of computer programs 
1 to be tested. The CPP generates a syntactically correct program file from a successfully compiled 
PLM86 program. CPP pre-formats and indents the original PL M86 source program file !ine-by-fine utilizing 
the program coding standards which follow. CPP does not alter the execution of the original source code. 
35 but merely makes all PLM86 source code programs appear to be very similar in format, irrespective of who 
the original programmer was. This standardizing of the program's format makes it more understandable to 
an individual other than the originator of the code. It also facilitates the implementation of other pre- 
processors, i.e. PPP 4, CCP 7, PCG 5. CIP 8, etc., without which it would have been very difficult for them 
to handle all the varying codes' styles in formats encountered from programmer to programmer. 
40 The block structure of the PLM86 language is emphasized in the reformatting to ensure that the 
program is easy to read and that its function is ciear. The following rules show how block structures are 
formatted in the exemplary system. Of course, the particular rules selected are not critical as long as the 
objective of achieving a standardized format is realized. 

45 

A. Indentations 

Indentations will be 2 spaces. 

50 

B. *DO' Statements 

The opening 'DO' statement and its corresponding 'END' statement will have the same left justification. 
Within the block, statements will be indented. Each new level of nested block within a block produces 
55 further indentation. Complex 'DO' blocks may have labeled outer 'DO' and 'END' statements. Caution is to 
be used when labeling inner blocks because it disturbs the indentation structure and clarity; comments 
should be used instead. 

All expressions used in 'DO CASE' or 'DO WHILE' statements will be enclosed in parentheses. An 
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examoie of a taoeied 'DO WHILE' block with a nested inner 'DO-END* block is snown in Figure 3. 

'DO CASE' oiocks must certain an enclosing DO' and 'END* arouna expressions to help =centify paths 
outlined by sucn blocxs. Statement laoeis or comments may be used on the first line of every case. Every 
DO CASE' biock must ce preceded by a check for valid index range. A 'DO CASE' block with 'DO* ana 
"END' delimiters for each individual case, is shown m Figure 4. A 'DO CASE* block with "DO* and 'END* 
delimiters for each individual case as well as comments is shown m Figure 5. 

C. 'IF* Statements 

The evaluation expression will always be enclosed in parentheses and executable statements will 
always be indented. 'DO* blocks should be used at all times. When 'DO* blocks are used, the rules 
concerning them will apply. THEN' will appear on the same line as the 'IF*, with the 'DO* starting on the 
next line with proper indentation. 

'ENDIF' is literally defined as 'DO:END' and is used to close off an 'IF' block. It will be left justified with 
the beginning 'IF'. 

When 'IF' statements are nested after the THEN', 'DO* blocks and the 'ENDIF' construct must always 
be used. 

When sequential 'IF' statements are used {'IF' statements nested after the 'ELSE'). '00* blocks must 
always be used around the 'IF statements. An example of the nested and sequential constructs is shown in 
Figure 6. 



2. Dual Case Alphabet 

The ability to use upper and lower case letters allows another level of clarity to be added to the source 
code. Under this rule, upper case letters are used for block structure related words, such as for example 
'DO', 'ENDS'. 'IF', et cetera, while lower case letters are used for all else. 



3. Comment Structure 

Comments within code should be at the first column or starting at the same column position, as the 
indented code on the preceding line of code being commented. A comment may be used before a 
complete block of code to explain its functionality. 

An example of a segment of a program reformatted in accordance with the above rules is shown in 
Figures 7a and b. 

The next processor is the Procedure Parser Processor (PPP) 4. PPP is utilized to automatically select 
"the" proper program to be tested (i.e. verified) from a PLM86 source file which may contain many 
programs. This eliminates the possible error(s) introduced by the individual verifiers if they were to 
manually cut and paste the original PLM86 program source file to extract the desired program. PPP 
requires that the PLM86 source file must have been run through the CPP pre-processor first. 

PPP extracts the following from the CPP'd PLM86 program source file: 

1. 'The header portion of the 'MODULE' (i.e. TA028.HDR). 

2. The designated 'UNIT (or subprogram) within the 'MODULE' to be verified (i.e. TA02823). 

3. The end portion of the 'MOOULE* (i.e. TA002.END) 

It then generates a modified PLM86 program source file which is identified, for example, as (TA02823 
PLM) and consists of the following: 

1. The extracted header portion of the original 'MODULE' (i.e. TA028.HDR). 

2. Immediately followed by the insertion of a 'MARK"/ character string to denote the state of the 
'UNIT' (i.e. subprogram) to be verified. 

3. The extracted 'UNIT' to be verified (i.e. TA02823 UNT). 

4. Immediately followed by the insertion of a "MARK END* character string to denote the end of the 
"UNIT" to be verified. 

5. The extracted end portion of the original 'MODULE' (i.e. TA023 END). 
Thus, the output of PPP (i.e. TA02823.PLM) has the following structure: 
TA028.HDR Original header from TA028.PLM 

"MARK* Commented 'MARK 1 statement 
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TA02823.UNT Specific TA028 'UNIT' under test 

'MARK END* Commented 'MARK END* statement 
TA028.ENO Original end from TA028.PLM 

This modified source file is used as the working copy of the unit to ce verified. 

The next processor is the pseudocode generator (PCG) 5 which <s entirely informational and does not 
effect the working copy of the program. The PCG takes the program "UNIT* extracted frcm the module by 
the PPP and performs two functions. First the procedure scans the code and iaentifies any rxec-tabie 
instructions that could result in the transfer of program control via brancning within the program. This 
methodology is based upon what is defined as a "BLOCK" of code. A "BLOCK" of code consists of a 
series of executable software statements that are always executed from beginning to end tn the same exact 
order. Normally these "BLOCKS" of code are separated by what is known as "CONTROL" statements 
which in turn determine which "BLOCK" of code is to be executed next. Each "BLOCK" of cede ;s 
identified with a multiple-digit numeric code known as- its "BLOCK Each "BLOCK" of code is also 
assigned a "LEVEL #" which identifies the "BLOCKS" nesting level. The "nesting level of a "BLOCK" of 
code is a measure of how many control statements must be executed in order to reach that "BLOCK" of 
code. The PCG deletes all of the text between the control statements and puts in its place a simple 
"BLOCK nn" comment statement where "nn" describes the block number in its sequential position from the 
beginning of the program. The purpose of this is to highlight the areas of code that must be tested for 
verification. Figure 8 illustrates the pseudocode generated by PCG for the unit shown in Figures 7a and b. 

The second function of PCG is determining all possible branching within the program unit. In performing 
this function PCG generates two data tables. The first is the block data table, an example of. which follows 
and is identified as Table 1. This table identifies the block number, the level number and the contiguous 
block, which is the path by which the block is entered. 

The level number in the block data table indicates the nesting level of the block. A counter which keeps 
track of the nesting level increments with 'DO* statements and decrements with 'END' statements. Finally, 
the block data table indicates whether the block is a loop-back block with a "T" if it is "true and an "F" if it is 
false. 



TABLE 1 
BLOCK DATA TABLE 



Block# 

1 
2 
3 
4 
5 

- 6 
7 
8 



Level# 

1 
2 
3 
3 
4 
3 
4 
3 



Contiguous 
Blocktt 



0 
1 
2 
2 
4 
2 
6 
2 



Loop-back 
Block 



F 
F 
F 
F 
T 
F 
T 
F 



The second table generated by PCG is the linkage table identified as Table 2 below. This Table defines 
all the possible branching that can occur when the code is executed. 



TABLE 2 

LINKAGE TABLE (1,2) (2.1) (2.3) (3.2) (2.4) (4,2) (4,5) 
(5.4) (2,6) (6.2) (6.7) (7,6) (2.8) (8.2) 



PCG combines the pseudocode along with the two data tables into a single common output file 6, for 
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.r.stance. TA02823.PCG. which is used for final documentation. 

The Commentea Code Processor tCCP) 7. iike PCG. utilizes the output from PPP as its input. CCP ;s 
similar to PCG. <n fact the two processors have common code that both utilize. Whereas PCG was for 
nformational use only ;o the verifier. CCP is vital to the proper operation of the coae instrumentation 
s processor (CIP) 8. As with PPP and PCG. CCP helps to minimize erronsj introduced by the individual 
verifier by utilizing a standard, consistent set of rules independent of the code being verified. CCP searches 
the code line-by-Hne for the same control statements as PCG. This time, however, code >s not deleted, but 
non-executable comment cards are inserted into the target code to mark the beginning and ;he end of each 
block of code. Thus CCP identifies each "BLOCK* with the unique "BLOCK # n which t s identical to that 

ro assigned by PCG to the same block of code. In addition. CCP inserts a commented 'DO' statement (i.e. 
*DO") immediately preceding each "BLOCK" of code and a commented 'END' statement (i.e. 'END* ) 
immediately following each "BLOCK" of code. It also distinguishes between the 'END' statement for a 
normal 'DO' 'END' 'BLOCK* construct and the 'END' statement for a toop-type 'DO' 'BLOCK' construct (i.e. 
'END. FOR*. 'END WHILE*, etc.). It also indicates which commented 'DO' and 'END' statements it has 

is inserted within the program by placing an ""ADDED BY CCP"'" PLM86 comment statement beside them. 
This is for traceability purposes only and is not utilized by CIP. 

CCP writes this commented 'DO END' version of the program source code to a file (i.e. TA02823.PRE). 
CCP also generates the same two data tables as PCG. but writes them to a separate file (i.e. 
TA02823.TAB). Both of these files are utilized by the Code Instrumentation Processor (CIP) 8. 

20 The Code Instrumentation Processor (CIP) 8 utilizes the comments added by CCP as markers to insert 
executable tracer instructions at the beginning and end of blocks of code between control statements, and 
to categorize each block with a sequential number. The blocks are numbered by CIP in the same way that 
the PCG procedure numbers the blocks. The executable instructions set the value of an element in a one 
dimensional array to the respective block number when that block is entered and the block to which control 

25 reverts when the block is exited during execution. In this manner, a tracing of the program execution path 
may be easily generated by printing out the array values, which will show entry into and exit from "each 
block executed in the program. 

CIP also identifies which executable statement it has inserted into the program by placing a " 'ADDED 
BY CIP"*" PLM86 comment statement beside them. It also identifies the actual "BLOCK#s" that it has 

30 assigned when processing CCP's commented single 'DO' and 'END' statements by placing a " 'BLOCK 
nn'" PLM86 comment statement where "nn" is the actual "BLOCK #" assigned by CIP at the beginning 
and end of each "BLOCK". As with CCP, this is done for traceability purposes only. 

Figures 9a. b. and c illustrate the fully instrumented piece of code shown in Figures 7a and b. As can 
be seen, each of the blocks is sequentially identified in the same manner as in the pseudocode of Figure 8 

35 by the "BLOCK nn" comments such as for instance the comments 24 and 25 at the beginning and the end 
of Block 3 respectively. 

The executable tracer instructions used in the instrumented code of Figures 9a, b and c are the 
ACTLINKS statements which write the appropriate block number in a one dimensional array at a location 
indicated by TRACEINX. For instance, the ACTLINKS statement 26 writes into the array the numeral "3 n 

JO indicating that the block 3, has been entered. The numeral w 3" is stored in the array at the location 
indicated by the value of TRACEINX. TRACEINX is then incremented by one as indicated at 27 in 
preparation for the next entry. At the end of block 3 another ACTLINKS statement 28 inserts a "2" in the 
one dimensional array indicating that control has been transferred back to block 2. Again TRACEINX is 
incremented by 1 in preparation for the next entry as at 29. 

45 The instrumented code of Figures 9a. b and c also illustrates another feature of the invention. It will be 
seen that block 3 calls another routine identified as "deadman" as indicated by the statement "call 
deadman" 30. CIP inserts before the call statement a series of statements which print out as the program is 
executed "before deadman". These instructions include a move byte instruc tion 31. a write to output file 
instruction 32 and a line feed instruction 33. Similarly after the call instruction, the CIP processor inserts 

so instructions which write to the output file, "after deadman". implemented by the instructions 34, 35 and 36. 
This sequence verifies that the target routine reached the instruction to called the external routine and that 
the program returned from the called routine to the proper place in the target program. Although not 
implemented by the code shown in Figures 9a, b and c the CIP processor can also provide for writing to 
the output file the values of the target unit variables both before and after the transfer to the called routine 

55 to monitor any affect that routine may have on the variables. 

At this point, the target code has been reformatted and all possible areas of branching have been 
identified with a block number. Also code has been inserted within the target code to set the appropriate 
value in a one dimensional array of the block number when that particular section of code is executed. Also 
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code has been inserted to verify that the program returns to the orooer piace from a called routine, and if 
desired, the values of the vanaoles before and after the call. Up to this point the oniy input reauirec from 
the verifier was the sequential position of the program to be extracted from the module. 

The verifier must now become familiar with the computer program software design specification 2 

5 written by the programmer describing exactly the function and purpose of the program. Also, the verifier 
must become familiar with of the actual target code which is contained in the fiie 1. The verifier must 
visually analyze and compare the target code against the design specification 9. With this information, the 
verifier must determine 10 input values and expected output values that will be used to test the target cede. 
The pseudocode, block data table and block linkage table generated by PCG at 5 are useful m enabling the 

10 verifier to devise input values that will execute each of the blocks m the target code. With the 
input/expected output values determined, this data along with appropriate identification for the aifferent test 
cases must be manually input to the test generator processor (TGP) 12. 

The Test Generator Processor 12 is used to request and receive data from the verifier in a user-friendly 
format and to arrange it in a formatted manner compatible with the target code. TGP also ensures that the 

/5 verifier has entered a complete and consistent set of data. A user Specified Information file list generated, 
also referred to as the variable file, by TGP is divided into sections. An example of such a file list is shown 
in Figures 10a, b and c. The first line 37, or file header indicates the data and time of generation of the file 
and the version of TGP. This provides an audit trail of each execution through the test bed. Section 0 
indicates the procedures and/or functions called; in this case the "deadman" routine. The lines preceded by 

20 asterisks are comments which identify the information by column appearing in the line 39. For instance the 
called procedure or function name is indicated in columns 1-31. In this case "deadman" only takes up 
columns 1-7. The file identifier, TA03801. is recorded in columns 32-38. 

Section 1, identified by the reference character 40, records general information about the target 
program, including such things as the number of test cases and the array sizing used. 

25 Section 2, identified by the reference character 41, records specific information about each of the 

variables, with two lines dedicated to each variable. The comments indicate the data recorded it in each 
column of the file including the name of the variable to be monitored, its data type (8-Byte. C-Character, D- 
Double Word, H-Hexidecimal, l-lnterger. L-Logical, P-Pointer. R-Real. W-Word. X-Hexidecimal Word. Y- 
Hexidecimal Double Word.) an array designator, an input designator, an output designator, and a scoring 

30 type (A-Argument. G-Global, L-Local, M-Module. ©-Special scope for variable located "AT" a. specific 
memory location). Column 78 is an all case designator which is a Y if that variable is used in all of the test 
cases. The second line, for instance 42 for the variable SEQ. indicates the test cases in which that variable 
is used. For instance, all four of the variables in the exemplary program are used in all three of the test 
cases. 

35 Section 3, identified by the reference character 42, records the initial value for each of the variables 

for each of the test cases. In this instance the test cases are identified by the numerals 00, 01. and 02. 

Section 4 of the TGP information file list, identified by the reference character 43. lists the call of the 
unit being tested with the required argument list. 

Section 5. identified by the reference character 44, lists the value expected for each output variable 
40 for each test case and provides an array index if the variable is an array. 

A comment section, not shown, is provided as Section 6 for the user to add any test specific 
information to be noted during test execution. 

The data generated by TGP is saved to a file with a 7 character identifier as the file name with the 
extension .VAR, for instance, TA02838.VAR. The interface management system used to input information 
45 provided by the user was developed in the exemplary system using the Forms Management System on a 
VAX 780 and a VAX 8600 computer. The source program for the test generator processor was developed 
using the FORTRAN programming language, also on a VAX 780 and a VAX 8600. 

The formatted file from TGP is used by the Test Data Processor (TDP) 13 to generate a software test 
specification 14 as well as test driver program. An example of the pertinent portions of a test driver program 
so generated by TDP is illustrated in Figure 11. After declaring the variables (not shown in Figure 11), an 
execution loop statement 44 containing the number of test cases derived from the variable file is inserted. 
The test program is then assigned a block identifier of "1" by an ACTLINKS statement 45. This block 
number is written to the one dimensional block linkage array as the test program is executed to generate a 
tracer to the output indicating that the test program has been run. Next in Figure 1 1 . are the statements for 
55 inputting the assigned values for each variable in each test case and for writing the test case number along 
with the input values and expected values to the output file as indicated at 46. 

The test driver program then calls 47 the procedure/function target code to be verifier along with the 
corresponding argument list from the variable file. This is followed by a statement 48 calling for instructions 
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to control the output format and another ACTLINKS statement 49 indicating that the test program has been 
completed. 

Finally :he :est driver program includes execution statements 50 which write output vanaDie values anc 
block linkages generated by each test case to the output file. 

5 The software test specification generated by the Test Data Processor describes the test program 

identifying the expected block linkages for each test case, as well as providing a repeat of the input vaiue 
and the inspected output values input earlier by the verifier. The software test specification (STS) file 14 
does not contain program execution results, although it is still a very important part of the overall program 
documentation t9. Portions of the STS are illustrated in Figures 12 and 13. Figure 12 illustrates the general 

to input and output data. Figure 13 illustrates one of the test cases, in this case, test case 0. The sequence of 
block execution is indicated as at 51. The M 1 n, s at the beginning and end of the sequence indicate 
execution of the test program itself. The STS also indicates the values of the input variable 52 and the 
expected values of the output variable 53. A similar record is generated by STS for each test case. 

At this point the target code at 8 has been conditioned so that the path of program execution and the 

is input output variable results will be recorded on an output file. A separate test driver program 15 has also 
been generated and calls the instrumented target code under test while also recording all the input output 
variables on the same output file. A program Compile. Link and Locate processor (PCL) 16 links the 
instrumented target code which is the output of CI P 8 with the test driver program 15. 

Actual execution of the test program 15 and target code is implemented utilizing SED processor 17. In 

20 the exemplary embodiment of the invention, in which a VAX computer was utilized for the processors, an 
emulator was employed to execute the PLM 86 code of the target program. Execution of the test driver 
program/target code results in writing to the test results output file 18 the actual output values generat d 
and the block linkages for each test case. An example of the formatting output results is shown in Figure 

14. The final documentation 19 of the program verification process includes in addition to the test result file 
25 18. the STS file 14 which defines the input value (s). expected output value (s). expected block linkage (s) 

and rationale for each test case to be performed, and the PCG output file 6 which identifies the pseudocode 
structure of the program to be verified along with its block numbers and valid block linkages. This 
documentation is analyzed to determine for each test case that the program execution path was correct and 
the actual output values agree with those that were expected. In addition, the determination must be made 

30 that all execution paths were tested. This can be accomplished automatically by comparing the block 
numbers m the block data table with the block numbers written to the output file during test execution to 
assure that each block has been executed at least once. With the actual output values in agreement with 
the expected output values, and all of the possible branching combinations adequately considered, the 
target program has been verified. 

35 The verification process can be carried out utilizing a computer system such as that illustrated in Figure 

15. This system includes a general purpose digital computer 54, which in the exemplary system was a VAX 
computer. The processors as well as the target program are stored in disc storage 55. A display terminal 56 
provides the interactive interface with the verifier for selection of the target unit and test case data. Hard 
copies of the results of the verification are generated on a printer 57. 

40 The disclosed system automates the previously labor intensive complex task of preparing code to 
execute a sufficient number of test cases to adequately verify the target program. In addition the design of 
the system is such that each processor performs a part of the whole task, and consequently modifications 
to the system may be easily made through changes in the individual processors. Another benefit of the 
system is that the software verification process is necessarily made more uniform. This benefit exists 

J5 regardless of the program to be tested or the verifier performing the test. Furthermore, the user-friendly 
format and codification of the verification process makes it possible for one of less skill to perform the 
necessary software verification. Finally, the system is capable, with modifications, of software verification of 
programs written in any computer language and for any application. 

While specific embodiments of the invention have been described in detail, it will be appreciated by 

so those skilled in the art that various modifications and alternatives to those details could be developed in 
light of the overall teachings of the disclosure. Accordingly, the particular arrangements disclosed are meant 
to be illustrative only and not limiting as to the scope of the invention whicrTis to be given the full breadth of 
the appended claims and any and all equivalents thereof. 
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Claims 

1. A method of verifying a computer program source code having known format and a series of 
program statements including non-control and control statements by which the program can branch to 

5 alternative program statements of the source code, said method comprising: 

operating a processor to standardize the format of the source code to a set of orescribed formatting 
standards to generate a reformatted source code; characterized by the steps of: 
selecting a target unit of the reformatted source code for verification: 
instrumenting said target unit of the reformatted code by operating a processor to divide said target 
10 unit into blocks of code, a block of code being marked by the non-control statements between control 
statements, and to insert into said blocks of code executable instructions to write an identifier into an output 
file for each block of code when it is executed; 

selecting test cases for said target unit of code with each test case comprising input values for 
variables in the target unit and expected output values, said test cases being selected such that each block 
/s of code in the test unit is executed; operating a processor to generate a test driver routine to implement 
said test cases; 

operating a processor to compile and link the test driver routine with the instrumented target unit of 

code; 

executing the compiled/linked test driver routine and instrumented target unit of code: and 
so generating an output presenting actual output values and expected output values for each test case, 

and a sequential listing from said output file of the block identifiers of the blocks of said target unit code in 
the sequence in which they were executed. 

2. The method of claim 1 wherein said instrumenting step includes operating a processor to insert non- 
executable comments with a unique block identifier at the beginning and the end of each block of code in 

25 the target unit, generating from the control statements and said block comments a block data table 
identifying the block by which each block is entered, the nesting level of the block, and any loop backs in a 
block and wherein the step of inserting executable write instructions into each block includes using said 
comments and block data table to insert at the beginning of each block an instruction to write the block 
identifier and to insert at the end of each block an instruction to write the block identifier of the block to 

30 which the target .unit reverts. 

3. The method of claim 2 wherein the step of generating an output includes generating a comparison of 
the block identifiers written to the output file during execution of a block of code and the block identifiers in 
the block data table. 

4. The method of claim 2 wherein said instrumenting step includes generating a block linkage file 
35 identifying all possible transitions between blocks of code in the target unit. 

5. The method of claim 2 wherein the target unit of code includes a call instruction calling an external 
routine, and wherein said instrumenting step includes: inserting an executable instruction before the call 
instruction to write to the output file an indication of the call and inserting after the call instruction an 
executable instruction to write to the output file an indication that the program has returned to the target unit 

40 of code at the correct location. 

6. The method of claim 5 wherein said instrumenting step includes inserting into the target unit before 
and after said call instruction, instructions to write to the output file the values of at least selected ones of 
the target- code variables, and wherein said step of generating an output includes generating from the output 
file representations of the values of said selected variables before and after the call. 

45 7. The method of claim 2 including generating a pseudocode for use in selecting said test cases by 
operating a processor to generate a separate file containing only the control statements of the target unit 
with non-executable comments inserted in place of the non-control statements, said comments identifying 
said blocks with the same identifiers as the comments inserted in the target code by said instrumenting 
step. 

so 8. The method of claim 1 wherein the step of selecting test case includes operating a processor to 
generate a variable file for the test cases listing input and output variables for each test case along with the 
input value for each input variable and the expected value for each output variable, and said method further 
including when a program revision calls for a change in a designated variable, searching said variable file to 
identify the test cases which utilize said designated variable. 

55 9. The method of claim 1 wherein said step of operating a processor to generate a test driver routine 
includes generating a software test specification listing the values of variables used by the test driver to 
implement the test cases and the expected values of output parameters. 
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10. " A system for verifying computer program source code having a known format and a senes of 
orogram stat ments. mciuaing non-control and control statements by which the prcgram can branch ;o 
alternative program statements of the source code, said system comprising: 

means for instrumenting the source code by dividing the source code into blocks of code, a block of 
5 code being the non-control statements between control statements, and to insert into said blocks of code 
executable instructions to write to an output file an identifier for each block of code when it is executed: 

means for generating a variable file containing the input value of selected input variables of the source 
code and expected output values for output variables of the source code for selected test cases, saia test 
cases being selected such that each block of code is executed: 
w means for generating a test driver routine utilizing the values in the variable file to implement the test 

cases: means to 

compile and link the test driver routine with the instrumented source code: 

means for executing the compiled/linked test driver routine and the instrumented source code: and 
means for generating an output presenting actual output values and the expected output values for 
is each test case, and a sequential listing from said output file of the block identifiers of the blocks of said 
source code in the sequence in which they were executed. 

11. The system of claim 10 including: 

means to reformat the source code to a set of prescribed formatting standards to generate a 
reformatted source code: and 
20 means for selecting a target unit of the reformatted source code for instrumentation by said 

instrumenting means. 
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• xl: DO WHILE (T«st2 < 5.0); 
<t at«m«nt2; 

DO Ind«x=Start to Finish; 
stat«m«nt3; 
• tat ifn«nt4; 

END ; 

«tat«m*nt5; 
END mx I ; 

FIG. 3. 



DO CASE (Ind«x); 
I nd«xO:D0; 
• t gt«m«ntO; 

END; 

I nd«x t :DOs 
9 1 at«m«nt I ; 

END; 

I nd«x2: DO; 
* t at «m«nt2; 

END; 
END; 

FIG. 4. 



DO CASE (Cond 1 1 I on) ; 
DO; 

/ *eond Itlon Is 0 ♦/ 
ttat «m«n t ; 

END; 
DO; 

/ ♦ condt t Ion I* I ♦ / 

• tat «m«nt j 
itai tm«nt ; 

END; 
DO; 

/ ♦condl t I on I • 2 ♦/ 

• tat «m«nt ; 

END; 
END; 

FIG. -.5. 
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IF (Eval_«xp) THEN 

00; 

s t a t «8 ; 

END; 
ELSE 

/♦ «xpr«*«lon Is fals*-*/ 

00; 

IF (Eval_«xp) THEN 
00; 

•tat«9; 
ENO; 
ELSE 
00; 

• tat« I 0; 
ENO; 
ENDIF; 

/♦ «rtd of fal«« eo<« ♦/ 

ENO; 
ENDIF; 



FIG. 6. 



NV_WR I TE_SEQ : PROCEDURE ( S« q , p t r_ t o , p t r_f r om ) PUBL I C ; 
/ ♦ BLOCK 02 ♦/ 
IF SEQ = 3 THEN 

00; / ♦ BLOCK 03 ♦ / 
END; / ♦BLOCK 03 ♦/ 
IF SEQ > 0 AND SEQ < 3 THEN 
00 CASE S«q; 

KO:DO; /♦BLOCK 04- ♦/ 

DO WHILE (COUNT < 2); /♦BLOCK OS ♦/ 
END; /♦ BLOCK 05 ♦/ 
END KO; /♦BLOCK 04 ♦/ 
KI:DO; /♦BLOCK 06 ♦/ 

DO COUNT = 0 TO 2; /♦BLOCK Q7 ♦/ 
END; / ♦ BLOCK 07 ♦/ 
END K I i / ♦ BLOCK 06 ♦/ 
K2:D0; /♦ BLOCK 08 ♦/ 
END K2; /♦BLOCK 08 ♦/ 
END ; 

END NV_WRITE_SEQ; / ♦BLOCK 02 ♦ / 
END DIAGNOSTIC MODULE; 



FIG.. S. 
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/ ♦ MARK ♦ / 

NV_WR I TE^SEQ s PROCEDURE (S«q,ptr_to,ptr_from) PUBL I C ; 
/ ♦ DO ♦ / / ♦ ADDED BY CCP ♦ / 

DECLARE COUNT BYTEs 

DECLARE ( p t r_J o , ptr_from) polnttn 
DECLARE Nvram_Byt« bas«d ptr_to byt«; 
DECLARE ram bas«d ptr from byt«; 
DECLARE (S«q, t«mp) byta; 

5EQ = 5EQ + I : 
IF SEQ = 3 THEN 
DO; 

/ ♦ DO ♦ / / ♦ ADDED BY CCP ♦ / 

call d«adman ; 
/ ♦ END ♦ / / ♦ ADDED BY CCP ♦ / 

END; 
VVJENDIF; 

IF SEQ > 0 AND SEQ < 3 THEN 
DO CASE S«q; 
KO:DO; 

/ ♦ DO ♦ / / ♦ ADDED" BY CCP ♦ / 

DO WHILE (COUNT < 2); 

/ ♦ DQ_WHILE ♦ / /♦ADDED BY CCP ♦ / 

/♦ «ra«« mod* ♦ / 

nv portcsnv porte and OCFH; 

Nvrom By t» =0; 
/ ♦ END_WHILE ♦ / / ♦ ADDED BY CCP ♦ / 

END; 

/ ♦ END ♦ / / ♦ ADDED BY CCP ♦ / 

END KO; 



FIG. 7a. 
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Kl :D0; 

/ ♦ DO ♦ / / ♦ ADDED BY CCP ♦ / 

DO COUNT * 0 TO 2i 

/ ♦ DO_FOR ♦/ / ♦ ADDED BY CCP ♦ / 

/ ♦ dummy r«od ttrmlnatts «ra«« eye I • ♦ / 

n y P o r t c =n v portc op 030H; 

tomp = Nvram By to > 

/ ♦ wr I t • mod* ♦ / 

n^_po rt c=nv_port c and OEFH; 

Nvram__Byto = Rami 
/ ♦END_FOR ♦/ / ♦ ADDED BY CCP ♦ / 

END s 

/ ♦ END ♦ / / ♦ ADDED BY CCP ♦ / 

END K I ; 

K2:D0; 

/ ♦DO ♦/ / ♦ ADDED BY CCP ♦ / 

/ ♦dummy r«ad ttrmlnat«« wrlto cyclo ♦ / 

nv portesnv portc op 030H; 
tomp = Nvpqm Byto: 
/ ♦END ♦/ /♦ ADDED BY CCP ♦ / 
END K2; 
END i 
VV_ENDIF? 
/ ♦ CASES ♦ / 

/ ♦END OF IF THEN CONDITION ♦ / 
/ ♦END ♦/ /♦ADDED BY CCP ♦ / 

END NV_WRITE_SEQ; 

/ ♦ MARK_END ♦ / 

END DIAGNOSTIC_MODULEs 



FIG. 7b. 
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VVJENDIF; 

IF SEQ > 0 AND SEQ < 3 THEN 
00 CASE S«q; 
K0:00s 

/ ♦ DO ♦ / / ♦ ADDED BY CCP ♦ / / ♦ BLOCK 04 ♦ / 

ACTLINKS(TRACEINX) = 4 5 /♦ADDED BY CIP ♦/ 
TRACE I NX = TRACE I NX + I; /♦ADDED BY CIP ♦/ 
DO WHILE (C0UNT<2) 5 

/ ♦ DO WHILE ♦ / / ♦ ADDED BY CCP ♦/ / ♦ BLOCK OS ♦/ 

ACTLINKS(TRACEINX) = 5; /♦ADDED BY CIP ♦ / 

TRACE I NX « TRACE I NX ♦ I ; /♦ ADDED BY CIP ♦ / 

/♦ mraa* mod* ♦ / 

nv portcsnv portc and OCFHj 

Nvram Byt« = 0; 

ACTL I NK S ( TRACE I NX ) = 5s /♦ADDED BY CIP ♦ / 

TRACE I NX = TRACE I NX + I; /♦ADDED BY CIP ♦ / 

/ ♦ END_WHILE ♦ / / ♦ ADDED BY CCP ♦ / /♦ BLOCK 05 ♦ / 



END; 

ACTLINKS(TRACEINX) = 4 

TRACEINX=TRACEINX + I 

ACTLINKS(TRACEINX) ~ 2 

TRACE I NX = TRACE I NX + I 



/♦ ADDED BY CIP ♦ / 
/ ♦ ADDED BY CIP ♦/ 

/♦ ADDED BY CIP ♦ / 
/ ♦ ADDED BY CIP ♦/ 



/ ♦ END ♦ / / ♦ ADDED BY CCP ♦ / / ♦ BLOCK 04 ♦ / 

END KO; 
K I : DO ; 

/ ♦ DO ♦ / / ♦ ADDED BY CCP ♦ / / ♦ BLOCK 06 ♦ / 

ACTL I NKS ( TRACE I NX ) = 6; /♦ADDED BY CIP^ / 



FIG. 9b. 
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TRACE I NX=TRACE I NX + Is / ♦ADDED BY CIP ♦ / 
DO COUNT - 0 TO 2; 

/ ♦ DO_FOR ♦ / . / ♦ ADDED BY CCP ♦ / / ♦ BLOCK 07 ♦ / 

ACTL I NKS ( TRACE I NX ) = 7; /♦ADDED BY CIP ♦ / 

TRACE I NX s TRACE I NX + I; /♦ADDED BY CIP ♦ / 
/ ♦dummy r«ad ttrmlnqtti «ra«« cycl« ♦ / 

nv perte'n v p ortc op 030H; 

t«mp = Nvram Byte; 

/ ♦writ* mod* ♦ / 

nv poptc=nv_portc and OEFH; 

Nvpam_Byt« = Ram; 

ACTLINKS(TRACEINX) = 7; /♦ADDED BY CIP ♦ / 
TRACE I NX = TRACE I NX + Is /♦ADDED BY CIP ♦/ 

/ ♦ END_FOR ♦/ / ♦ ADDED BY CCP ♦ / / ♦ BLOCK 07 ♦ / 

END; 

ACTLINKS ( TRACEINX ) = 6 s /♦ADDED BY CIP ♦ / 

TRACE I NX = TRACE I NX + I; /♦ADDED BY CIP ♦/ 
ACTLINKS (TRACEINX ) = 2; /♦ ADDED BY CIP*/ 

TRACE I NX = TRACE I NX + I; /♦ ADDED BY CIP ♦/ 

/ ♦ END ♦ / / ♦ ADDED BY CCP ♦ / / ♦ BLOCK 06 ♦ / 

END K I ; 

K2:D0; 

/ ♦DO ♦/ / ♦ADDED BY CCP ♦/ / ♦BLOCK 08^/ 

ACTLINKS ( TRACEINX )= 8; /♦ADDED BY CIP*/ 
TRACE I NX = TRACE I NX + I; /♦ADDED BY CIP*/ 
/ ♦ dummy rtad t«rm lnai«« wpl t« eye I • ♦ / 

nv portesnv popte op 030H; 

t «mp = Nvpqm Byt«; 

ACTLINKS (TRACEINX ) = 2 s /♦ADDED BY CIP*/ 

TRACE I NX = TRACE I NX + I s / ♦ ADDED BY CIP ♦ / 
/ ♦ END ♦ / / ♦ ADDED BY CCP ♦/ / ♦ BLOCK 08 ♦/ 

END K2s 
END; 
Vvl_ENDIF; 
/ ♦Ca»«« ♦/ 

/ ♦END OF IF THEN CONDITION ♦/ 

ACTLINKS ( TRACEINX )= 2; /♦ADDED BY ZIP*/ 

TRACEINX » TRACE I NX + I; / ♦ AOOED BY ZIP*/ 

/ ♦END ♦ / / ♦ADDED BY CCP ♦/ / ♦BLOCK 02 ♦/ 

END NM_WRITE_SEQ; 

END D I AGNOST I Q_MODULE } 



FIG. 9c. 
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\ DO VV__=0 TO 2; 
TRACE I NX = 0; 
ACTL INKS (TRACE I NX) = I; 
TRACE I NX= TRACE I NX + I 5 
DO CASE VVJ i 
DOs / ♦ CASE = 0 ♦ / 

46- (l)(a««lgn Input valu** for + h I • iost ea««)i 

(2)(wrlt« t«»t ca»« #, Input valu«« and 
«xp«ct«d valutt to output fll«); 

ENO; 

DO; / ♦ CASE = I ♦ / 
(!) 

(2) 

END; 

DO; /♦CASE = 2 ♦/ 

(1) 

(2) - 

END; 

END; 

47 CALL NV_WRITE__SEQ ( SEQ . @ TQ_DATA* , @ FROM ) ; 

48- CALL(wplt« Instruction* for output format); 

49- ACTL I NKS ( TRACE I NX ) = I ; 

TRACE I NX =TR ACE I NX ♦ I ; 
DO CASE VV_J ; 

DO; / ♦ CASE = 0 ♦/ 

50- (l)(wrlta output volu«« to output fll«); 

(2)(wrlt« block linkage* to output fll«); 

END; 

DO; / ♦ CASE - I ♦ / 

(1) 

(2) 

END; 

DO; / ♦ CASE = 2 ♦ / 

(1) 

(2) 

END; 

END; 
END; 



FIG. I I . 
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2.3 Input and Output Dats(G«n«ra I ) 



VARIABLE NAME: SEQ 

CLASS t ARGUMENT 

TYPE: BYTE 

QUALIFIER VARIABLE 

DATA FLOW INPUT 

VALID VALUE RANGE: 1,2.3 



VARIABLE NAME: 

CLASS t 

TYPE: 

QUALIFIER 

DATA FLOW 

VALID VALUE RANGE : 



TO_DATA 

LOCAL 

BYTE 

VARIABLE 
BOTH 

0 - OFFH 



VARIABLE NAME: 

CLASS: 

TYPE: 

QUALIFIER 

DATA FLOW 

VALID VALUE RANGE : 



FROM 

LOCAL 

BYTE 

VARIABLE 

INPUT 

0 - OFFH 



VARIABLE NAME: 

CLASS: 

TYPE: 

QUALIFIER 

DATA FLOW 

VALID VALUE RANGE: 



NV_PORTC 

GLOBAL 

BYTE 

VARIABLE 
BOTH 

0 - OFFH 



FIG. 12. 
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TEST CASE #0 

TYPE OF TEST: 

STRUCTURAL AND FUNCTIONAL 
OPERATING MODE j 

NORMAL 
RATIONALE: 



T«*t path 
I . 2. 3, 2. 2, I . 

TIMING CRITERIA: 

N/A 

SIZE LIMITATION: 
N/A 

INPUT(S) AND VALUE(S): 
SEQ - 0 

TO DATA - 1 78 ^ — 52 



NV_PORTC =0 

EXPECTED OUTPUT(S) AND ITS (THEIR) VALUE(S) 

TO_DATA = 0 ^ 53 

NV_PORTC = 0 

MISCELLANEOUS INFORMATION OR COMMENTS 
PERTINENT TO THIS TEST CASE: 





FIG. 13. 
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